[mpls] draft-manral-mls-ldp-ipv6

I read the recently submitted subject draft with interest and have a few
comments/questions below.

Bob

* Page 2, Section 2.  LSP mapping procedures

Suggest the following wording for the bulleted item:

      -  If it is known that a packet must traverse a particular egress
         router, and there is an LSP that has an Address Prefix FEC
         element that is an IPv4 or IPv6 address of that router, then
         the packet is mapped to that LSP.  The procedure for
         obtaining this knowledge is beyond the scope of this
         document.

* Page 4, Section 4.  LDP Discovery

Suggest replacing "LSR's label swithing peers" with "LDP peers".

* Page 4, Section 4.1.  Basic Discovery Mechanism

For LDP peers connected by a single point-to-point link aren't Hello
messages for a single address family (either IPv4 or IPv6) sufficient?

Also, the term "socket" is not defined in the context of this draft.
The draft should restrict itself to talking about formats of packets on
the wire, rather than about implementation read/write concepts.

* Page 5, Section 4.2 Extended Discovery Mechanism

   "As Targeted Hellos will be sent to a particular preconfigured
address,
    we send the Hello only the socket of the same address family as the 
    configured address. If the address is configured for both IPv4 and
IPv6
    in that case we can send Hellos on the both IPv4 and IPv6 sockets."

I'm not sure what it means for an "address" to be "configured for both
IPv4 and IPv6".  Assuming that it means that targeted Hello's are
targeted for 2 addresses, one of which is an IPv4 address and the other
of which is an IPv6 address, without inspecting topology information
gleaned from an IGP how could a router determine if 2 such addresses are
for the same target?

* Page 5, Section 5. Maintaining Hello Adjacencies

   "An LDP session has multiple Hello adjacencies when a pair of LSRs is
    connected by multiple links that share the same label space; for
    example, multiple PPP links between a pair of routers. We can also
have
    multiple Hello adjacencies in the dual stack case where we have IPv4
    and IPv6 Hellos exchanged for the same label space between a pair of
    LSR's."

For peers directly connected by a single point-2-point link Hello's for
a single address family should be sufficient to allow estalishment of an
LDP session supporting label advertisement for both IPv4 and IPv6
addresses families.

For a set of peers connected by a single multi-access link it may not be
practical in general to limit Hello's to a single address family.

For targeted peers it may be difficult to prevent multiple hello targets
for the same peer.

* Page 5, Section 6.  Hello Message Procedures

   "However [RFC5036] states does not define the behavior of LDP in case

    both IPv4 and IPv6 transport addresses are sent in the packet.

    [RFC5036] seems to assume that only one such TLV is received 
    and specifies the behavior based on such a case."

One Transport Address TLV per Hello message is sufficient and should be
the goal.

A reasonable approach would be to permit an optional IPv4 Transport
Address TLV (but not an IPv6 Transport Address TLV) when the Hello
message is carried in an IPv4 packet and to permit an optional IPv6
Transport Address TLV (but not an IPv4 Transport Address TLV) when the
Hellos message is carried in an IPv6 packet.

* Page 6, Section 7.2  Session Initialization

My opinion is that IPv6 label distribution should be assumed to be "off"
for an LDP session until explicitly enabled by the LDP capability
mechanism.

This is the approach for all "new" FEC types (e.g., the mLDP FEC types),
and had the capability mechanism been part of the baseline LDP spec it
would have been the case for IPv4 and the AToM/L2vpn set of FEC types.

* Page 8, Section 8.1 Normative References

rfc5036 is missing from the list of normative references.
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls